โ RNS 1.4.2 released https://pypi.org/project/rns/
๐ฌค rns.recipes
top
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ Retichat.com Web LXMF Client (WIP) โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Started by jrl290 ยท 1mo ago
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-1
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ jrl290 #1 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 1mo ago
TL;DR: Just go to retichat.com
So I felt the need to AI-write a web implementation of Reticulum, called Reticulum-post.
For four reasons:
โข to harness the power of Reticulum in webpage form
โข to take advantage of a massive amount of cheap network infrastructure
โข to help make Retichat/RFed more accessible and build support for the extension
โข because we can
You may or may not imagine, it was a bit of a trick making Reticulum work with the
ephemeral nature of POST requests. But if LoRa and QR codes can carry Reticulum, HTTP
should be no problem.
Bidirectional initiation is straight forward. Just like LoRa, each node just pushes data
when it has something to say.
Web servers don't work like that. They're meant to be stateless. And servers generally
can't send data to a network address without the client initiating the connection first.
There is major efficiency to be gained from that. Maintaining connections is cumbersome.
Splitting up the process into self contained chunks allows servers to handle many
requests from many machine without trying to remember the state of each machine (mostly)
Reticulum works really well in that format. It is designed to be asynchronous and
sometimes sparse. As the spec says: as low as 5 bits per second. So this implementation
takes all of Reticulum's packet building, relaying, path management, and clean up and
shoves it into a buffer, waiting for the next initiated "exchange". Clients merely poll
for both sending and receiving data, and the 0 data poll is very lightweight
That's the long and the short of it. It doesn't require anything on the server side
except php. In order to bridge it to the backbone network, I have my one rnsd node
polling (1 per second) with a custom interface, PostInterface. But ideally someone that
isn't behind a firewall would do a bidirectional bridge
As usual, this is heavily AI written and completely open source:
https://github.com/jrl290/Reticulum-post
https://github.com/jrl290/Retichat-js
And it is very early in development. It really only started out as a proof of concept and
now it is worth seeing to the finish. I think it is good to develop Retichat in parallel
so that I can stay consistent as I understand fully what shape it should take
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-2
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ jrl290 #2 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 24d ago
Still primitive, but foundationally much more fleshed out now. The php backend can
connect bidirectionally to another php backend or to the PostInterface extension to rnsd.
The javascript client still only polls via post requests. But it is still a complete
Reticulum node
Also, I have another server to continue developing on, so I'll leave retichat.com in a
stable condition for people who want to experiment with it
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-3
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ bergie #3 โ
โ f9477df559d52317 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 23d ago
Hmm, I think I need to add your POST interface to reticulum-js
โ 1 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-4
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ Zenith #4 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 23d ago
https://github.com/Quad4-Software/RNS-over-HTTP
There's been RNS over HTTP/S POST requests as an interface for quite a while
A better approach to Reticulum in the browser is using WebAssembly and sockets. While
possible, POST requests really aren't the right tool here. I would look into the Go ports
WASM build https://reticulum-go.quad4.io/wasm-example and rns-js
https://github.com/liamcottle/rns.js/
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-5
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ bergie #5 โ
โ f9477df559d52317 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 23d ago
Zenith wrote:
> https://github.com/Quad4-Software/RNS-over-HTTP
> There's been RNS over HTTP/S POST requests as an interface for quite a while
That's quite different, though, as it does point-to-point instead of client-server. Very
suitable for a "proper" Reticulum daemon (for example Python, Rust, Node.js) that needs
to pass its traffic as regular HTTP. But obviously wouldn't work in browser as we can't
serve HTTP there.
Still, I'm thinking to implement both in reticulum-js. Here's the POST client:
https://github.com/bergie/reticulum-js/commit/64e837c43d37ac9a135a91a2350da7e7c9407314
> A better approach to Reticulum in the browser is using WebAssembly and sockets. While
possible, POST requests really aren't the right tool here. I would look into the Go
ports WASM build https://reticulum-go.quad4.io/wasm-example and rns-js
https://github.com/liamcottle/rns.js/
WASM won't really solve anything, you still can't get out of the browser sandbox.
But yes, rns.js does exist but hasn't been maintained. In the end I decided to start
reticulum-js from scratch to build 100% on the standardised web platform (so it'll work
now and in the foreseeable future) in both browser and Node.js.
โ 1 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-6
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ jrl290 #6 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 23d ago
>Hmm, I think I need to add your POST interface to reticulum-js
By all means! I had looked into WebSockets but it was pretty much impossible to host them
on my shared web hosting service. It makes me wonder why WebSockets aren't a first class
interface in rnsd. Seems the people with the server resources to host a backbone node
could easily add a Websocket interface. Even with PostInterface, the bridge rnsd on my
home network is in polling mode instead of bidirectional mode
> https://github.com/Quad4-Software/RNS-over-HTTP
> There's been RNS over HTTP/S POST requests as an interface for quite a while
I asked if there was an analogue in this post:
https://rns.recipes/forum/general/post-based-interface
I don't suppose you know of another browser LXMF client?
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-7
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ bergie #7 โ
โ f9477df559d52317 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 23d ago
jrl290 wrote:
> By all means!
It is now in reticulum-js git, in case you want to verify interoperability. I don't have
PHP environment handy to test myself.
There's also a Node.js HttpPostServerInterface in the repo.
> It makes me wonder why WebSockets aren't a first class interface in rnsd.
Until now there haven't been that many browser Reticulum participants. Maybe we'll see
this take off.
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-8
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ jrl290 #8 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 23d ago
Looks good at first glance
I'd just make sure to add the 'wake' alternative to polling in the Node.js server module.
I don't imagine anyone would want more than 1 or 2 polling connections if they can help it
โ 1 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-9
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ jrl290 #9 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 19d ago
In case anyone has been wondering about the inconsistent behavior of retichat.com, it's
because I was installing a true bidirectional POST interface bridge to the backbone
network. Now the only polling that occurs will be from the browser itself. Everything is
orders of magnitude faster that way.
If people want to write their own browser apps using PostInterface, you can have it point
to https://retichat.com/reticulum and it'll be connected to the full network. But of
course, I would very much appreciate it if someone else who has a backbone node would
add-on the PostInterface python interface here: https://github.com/jrl290/Reticulum-post
โ 0 โ 0 โค 0
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
post-10
โญโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ bergie #10 โ
โ f9477df559d52317 โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
โธ 19d ago
jrl290 wrote:
> If people want to write their own browser apps using PostInterface, you can have it
point to https://retichat.com/reticulum and it'll be connected to the full network.
This might be useful for bootstrapping. The WebRTC interface needs another Reticulum
connection first for signaling. Then the rest of the traffic (between WebRTC capable
clients) is P2P.
I plan to host couple of public Reticulum WebSocket servers, but it is always good to
have options.
โ 0 โ 0 โค 0
โ INFO โ Identify to this node to post. How?
bottom